Monster Media 1996 #14

home *** CD-ROM | disk | FTP | other *** search

/ Monster Media 1996 #14 / Monster Media No. 14 (April 1996) (Monster Media, Inc.).ISO / netmail / tgwav112.zip / WHATSNEW.112 < prev

Wrap

Text File | 1996-01-20 | 14KB | 269 lines

┌── · ▄▄▄. ────────────────────────────────────────────────────────────┐ │ .■▄█▀▀▀▀■. TGWave v1.12 - WHATS NEW IN THIS VERSION │ ■▄█░█▒ · ▄ Copyright 1995-1996 Lars Hellsten, All Rights Reserved │ ░███████▄▄▄▄██ Another great MatrixSoft product! │ ┌──────────────────────────────────────────────────────────────────────┐ └──────── Blue Wave / QWK offline mail door for Telegard v2.99 ────────┘ INTRODUCTION This file contains a list of major changes that have been made since the first release of TGWave. It is best when upgrading to a new version, to search this file for the release of the version you're currently running, and then read *UP* from that point. That way you see the changes in the order they were made. IMPORTANT: You MUST update your ENGLISH.TGW file by adding the new strings (documented below) that have been added since the previous version of TGWave and recompile. If you are using the default language file, then you can simply replace ENGLISH.TGW with the new default one found in the \SAMPLES\ directory. Remember to recompile using TGWLCOMP. Many of the new features will not work properly without an updated language file. The default menus and display files have also been updated in this version. You may wish to take a look at the TGW_MENU.ZIP and TGW_TEXT.ZIP files in the \SAMPLES\ directory when you're upgrading. HISTORY (%)=Bug fix, (+)=New Feature, (*)=Changed/Updated v1.12 released on Saturday, January 20 + Strings added: 108 `07There are file attaches available for download, press `0B* `07to edit queue!~SM~SM 109 `0CWarning! You have file attaches selected to be sent with this mail packet,~SMbut you are using a non-batch protocol. You must change to a batch protocol~SMin order for the file attaches to be sent.~SM~SM~SP ; 143: Colour of string 142 - displayed before it. 143 `0A ; File attaches: ~&1=Number of files, ~&2=Number of bytes ; 280 `03There are `0B~&1`03 file attach(es) available for download - press `0B*`03 to edit queue.~SM 281 ; ~&1=Filename, ~&2=Size, ~&3=Est. Time, ~&4=(##), ~&5=Selected? ; ~&6=Total files, ~&7=Total size, ~&8=Total Time 283 Selected 284 285 ~SC`08┌──── `0FStatus `08─── `0FFilename `08─────── `0FSize `08────── `0FTransfer Time `08──────────────────┐~SM 286 `08└─────────────────────────────────────────────────────────────────────────────┘~SM~SM 287 `07 ~EL5~&4`0B~EL10~&5 `03~EL12~&1 ~ER8~&2 bytes ~&3 minutes (approximate)~SM 288 ~SM `0B~&6`07 file(s) totalling `0B~&7`07 bytes attached, `0B~&8`07 minutes (approximate)~SM 289 ~SM`0AFilename or # to toggle, (L)ist Batch, (Enter)=continue? `07 290 LC 291 ~SM~SM`0FContinue... `07~SM~SM 292 `0C~SMThere aren't any files attaches available for download!`07~SM~SM 293 `0C~SMSorry, your access level does not permit you to download file attaches.`07~SM~SM 300 Don't flag any attached files 301 Files attached to new messages 302 Files attached to any messages 303 ~SC`0FSelect a method for automatically flagging file attaches...~SM~SM 304 `0ECurrent setting: `07~&1~SM~SM 305 `0B(1) Don't flag any attached files, let me do it manually~SM 306 `0B(2) Flag files attached to new messages~SM 307 `0B(3) Flag files attached to any messages~SM~SM 308 `0AFile attach flagging method (1-3), (Enter)=abort? `07 309 123 ; 310-312: File attach settings ; 313-314: Mail packet type ; 315-318: Password usage 310 Flag NONE 311 Flag NEW attaches 312 Flag ALL attaches 313 Blue Wave 314 QWK 315 <disabled> 316 Door Only 317 Reader Only 318 Door/Reader ; Uploads; ~&1=NEW or REP 330 `09■ `0BUpdating your configuration - `03 331 `03Done!~SM 332 `09▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄`01▄~SM 333 `19▒ `17Please begin your upload of `1F~EL8~*P.~EL3~&1`17 with `1F~EL29~VT `08█~SM 334 `01▀`08▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀~SM~SM~SM Strings changed: 106 ACLPS* <- (A)bort, (C)ount, (L)ogoff, (P)rotocol, (S)tart Transfer, (*) Edit Queue % Sped up the processing of reply packets a bit. It's still not incredibly fast, but I accidentally had TGWave not managing it's overlay file properly, and it ended up affecting that part of the code (and only that part) in a big way. * Lowered the stack space used from 40k (which was way too much, it was 32k in v1.01) to only 16k. If you encounter any stack overflow (#202) errors, please report it, with that section of your logs. % Fixed some memory eating problems - the areas selection and bundling routines were both in many cases allocating memory and not freeing it (that's what I get for using EXIT statements). This wasn't a major problem, and on most systems enough memory was available that it would go unnoticed, but it still shouldn't have been happening. * Replaced the default menu screens with newer ones that I thought look a little more professional - more blue-ish, more wave-ish. ;) * If the new files listing is an external text file (rather than the internal compiler), a new files listing will only be included in prescanned packets if the user has the "include files listing" option on, as opposed to always being included. % Sped up bundling and private message deletion slightly by eliminating some useless information TGWAVE was storing in order to delete messages. % Aarrrrruggh! I found the source of the slow initialization (the pause after the logo screen was displayed) on some systems. My ACS parsing routines were OPENING, READING FROM and CLOSING the GROUPS.DAT file EVERY time they encountered the "Cx" ACS command. I could hardly believe it when I realized what was happening. On my system, with about 300 message areas, and each message area having an ACS string such as CA|C@, it was opening and closing the file 600 times when initializing, and reading 1.6 megs total (I shudder at the thought of running it without a disk cache!), taking a good 5-10 seconds. * Sped up the PRESCAN mode dramatically as well while I was at it (see below), PRESCAN should scan AND bundle in almost the same time as it takes to scan from within the door. * Major changes were made internally to the way TGWave scans mail. It now when scanning only actually processes new messages (which is the way the CEC door works) as opposed to building data on every message in every base. It now builds data on other messages on the fly - if you issue the BO bundling command to bundle old messages, or the <area#>L<#msgs> command to bundle messages older than your lastread pointer, TGWave will go and quickly rescan the messages in that base that it hasn't already scanned (something BW doesn't do - with BW you can't use the L or B bundling commansd along with the filter, keyword or personal commands). If all the messages in a base are new, there will be no visible difference. If half the messages in a base are new, it should be about 50% faster. If no (or very few) messages in a base are new, scanning should be about 75+% faster than TGWave v1.10. Advantages of all this: (1) Scanning is way faster - it doesn't waste time gathering information about messages that wouldn't even be included in the user's mail packet. (2) When I put in k-byte limitations (PCBWave is my priority right now so this will have to wait until the next version) - it'll be totally dynamic, unlike BW, and similar to how the message limits work. Rather than just stopping when the limit is reached, it'll still let you manipulate the scan table with bundling commands as long as you don't go over the limit. Disadvantages (necessary tradeoffs): (1) Only files attached to new messages will be detected, although the BO or L bundling commands are used, it will pick up any files attached to old messages. (2) This one kinda bugs me - for the total # of messages it now uses the number of messages in the base (the # of records in the .SQI or .JDX file), whereas TGWave v1.10 stuck the total number of *available* messages in that field (so messages the user doesn't have access to weren't even listed). So for example, if you had 300 messages in the private messages area and typed "0L10", instead of bundling the last 10 personal messages, it would now look through the last 10 messages, and only bundle any personal messages contained in the last 10. So if you might type "0L10" and see a "3" show up in the "# DL" field. I think this makes the bundling command system much less elegant, although it's still better than the BW door, where it would display "10" in the "# DL" field, making you THINK there were 10 messages to be bundled, and then only actually bundle 3. In any case, tradeoffs are a fact of life, and I guess no one really notices things like this, so I shouldn't be upset. Sorry I couldn't condense that explanation a bit. * Another speed optimization - since TGWave scans through all the message areas on the system when it initializes (to determine which the user has access to), it didn't make sense to scan through all message areas a second time when building the scan table, so TGWave now creates the Blue Wave <bbsid>.INF file as soon as a user enters the door, and updates it before downloading mail (in case the user changed their settings). This means the door only needs to scan through selected message areas and doesn't need to output as much to disk when scanning, so scanning should be faster. % Fixed some problems with the logic the door was using to update lastread pointers, that may have been causing problems on message bases that weren't numbered starting at 1. * When in prescan mode, TGWAVE will no longer create empty mail packets. This means you can do things such as have TGWAVE bundle your own mail on a regular basis (whenever your system tosses mail for example) but not create an empty packet if there are no new messages in your selected areas, filling up your reader's download directory with tons of empty packets. % PRESCAN from a file (/PU:<filename>) wasn't working. TGWAVE was using /PS: as the parameter instead of /PU: which was displayed in the help screen. So it did work, it's just that no one knew the proper command for it. ;) /PU: now works and should process the user names listed in the specified file. % The "B" bundling command was marking the lastread pointer of affected bases as the last message in the base, always. It now uses the correct formula of LASTREADMSG+#BUNDLED, so if your lastread pointer was at message 50, and you bundled the first 50 messages, you'd get the remaining messages in the next packet. % The "BO" and "BN" (bundle old, bundle new) bundling commands actually work now. There was a condition missing in an IF statement that was causing them to be ignored - oops. + Added file attach support. There is now a "download file attaches" ACS in TGWSETUP, and a configuration option for users to toggle their flagging preference. The following command should be added to your TGW_CFG.MNU file (presuming you want users to be able to download file attaches): Cmd I,,&T,15 There is also a new MCI code, ~!A which returns the user's file attach flagging preference/setting. % TGWave (like Telegard) wasn't following the JAM specs correctly when deleting messages. This caused problems with some JAM utilities. Also fixed some problems with the way it was deleting messages from Squishbases, although I don't know what (if any) problems that was causing. % Fixed problem with it trying to toss all uploaded QWK replies to the e-mail base (resulting in a runtime error).